The present invention relates generally to object-based high level programming environments, and more particularly, to techniques for tracking references to objects defined in object-based high level programming environments.
One of the goals of high level languages is to provide a portable programming environment such that the computer programs may easily be ported to another computer platform. High level languages such as “C” provide a level of abstraction from the underlying computer architecture and their success is well evidenced from the fact that most computer applications are now written in a high level language.
Portability has been taken to new heights with the advent of the World Wide Web (“the Web”), which is an interface protocol for the Internet which allows communication of diverse computer platforms through a graphical interface. Computers communicating over the Web are able to download and execute small applications called applets. Given that applets may be executed on a diverse assortment of computer platforms, the applets are typically executed by a Java™ virtual machine.
Recently, the Java programming environment has become quite popular. The Java programming language is a language that is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java programming language (and other languages) may be compiled into Java Bytecode instructions that are suitable for execution by a Java virtual machine implementation. The Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set but, in general, may be software, hardware, or both. A particular Java virtual machine implementation and corresponding support libraries together constitute a Java runtime environment.
Computer programs in the Java programming language are arranged in one or more classes or interfaces (referred to herein jointly as classes or class files). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed without modification on any computer that is able to run an implementation of the Java runtime environment.
Object-oriented classes written in the Java programming language are compiled to a particular binary format called the “class file format.” The class file includes various components associated with a single class. These components can be, for example, methods and/or interfaces associated with the class. In addition, the class file format can include a significant amount of ancillary information that is associated with the class. The class file format (as well as the general operation of the Java virtual machine) is described in some detail in The Java Virtual Machine Specification, Second Edition, by Tim Lindholm and Frank Yellin, which is hereby incorporated herein by reference.
FIG. 1A shows a progression of a simple piece of Java source code through execution by an interpreter, the Java virtual machine. Java source code 101 includes the classic Hello World program written in Java. The source code is then input into a Bytecode compiler 103 that compiles the source code into Bytecodes. The Bytecodes are virtual machine instructions as they will be executed by a software emulated computer. Typically, virtual machine instructions are generic (i.e., not designed for any specific microprocessor or computer architecture) but this is not required. The Bytecode compiler 103 outputs a Java class file 105 that includes the Bytecodes for the Java program. The Java class file 105 is input into a Java virtual machine 107. The Java virtual machine 107 is an interpreter that decodes and executes the Bytecodes in the Java class file 105. The Java virtual machine 107 is an interpreter, but is commonly referred to as a virtual machine as it emulates a microprocessor or computer architecture in software (e.g., the microprocessor or computer architecture may not exist in hardware).
Typically, the data types supported by the Java programming language are supported by Java virtual machine implementations. This means that both primitive and reference Java data types are supported by Java virtual machine implementations. The primitive Java data types are relatively simpler and include integral types (e.g., byte, short, int, long, char). As such, the values of the integral types of the Java virtual machines are the same as those for the integral types of the Java programming language. However, the reference data types have values that can be references to dynamically created class instances or arrays (or class instances, or arrays that implement interfaces). It should also be noted that the reference data types are internally represented by the virtual machine.
In any case, the virtual machine needs to represent data types for various reasons, for example, to represent method signatures. A method signature describes the parameters and return type of a particular method. To illustrate, FIG. 1B depicts a method signature 120 in an internal method representation 122 which is generated by a virtual machine. The method signature 120 corresponds to a method foo 124. The method foo 124 has four parameters, namely, byte, java.lang.string, double and java.util.date. The signature 120 represents the data type of these four parameters. As such, the character “B” indicates that the first parameter is a “byte” type, “Ljava/lang/string” indicates that the second parameter is a “string” type, “D” indicates that the third parameter is a “double” type, and “Ljava/util/Date” indicates that the fourth parameter is a “date” type. It should be noted that “string” and “date” represent reference data types. Accordingly, there may be a need to access the string and date classes in order to execute the method. In other words, there may be a need to locate the internal representation for classes associated with the reference data types (e.g., string and date data types). This means that to execute a method, the virtual machine has to do some processing to parse the signature and determine the data type for the parameters.
One problem with the conventional representation of Java data types is that the method signatures have to be read sequentially since data types can have various lengths. This means that the method signature has to be sequentially scanned from the beginning in order to access a particular parameter's data type. Furthermore, after the data type has been determined, there is a need to perform more processing to locate the internal class representation of the method's parameters (e.g., look it up in a table). The amount of processing required to sequentially read and then find the appropriate internal class representation can adversely affect the performance of virtual machines. This can seriously hinder the performance of virtual machines, especially those operating with relatively limited computing power (e.g., embedded systems).
In view of the foregoing, there is a need for improved techniques for representation of Java data types in Java computing environments.